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ABSTRACT 

The  use  of  weakest-precondiuon  predicate  transformers  in  the  derivation  of  sequential, 
process-control  software  is  discussed.  Only  one  extension  to  Dijkstra's  calculus  for  deriving 
ordinary  sequential  programs  was  found  to  be  necessary:  function- valued  auxiliary  variables. 
These  auxiliary  variables  are  needed  for  reasoning  about  states  of  a  physical  process  that  ex¬ 
ist  during  program  transitions. 
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1.  Introduction 

For  the  past  tew  years,  we  have  been  exploring  the  use  of  assernonal  reasoning  in  the  construc¬ 
tion  of  process-control  software.  Our  intent  was  to  employ  an  existing  method,  perhaps  with  a  few 
extensions,  and  systematically  derive  process-control  programs  from  specifications.  Use  of  an  exist¬ 
ing  method  had  both  a  scientific  and  a  pragmatic  motivation.  The  scientific  motivation  was  based  on 
our  expectation  that  the  difficulties  we  encountered  by  using  an  existing  method  would  provide 
insights  into  what  distinguishes  process-control  programs  from  ordinary  sequential  and  concurrent 
programs.  The  pragmatic  motivation  for  using  an  existing  method  was  that  extending  a  well  under¬ 
stood  method  was  likely  to  be  easier  than  developing  a  new  method. 

Our  investigations  have  been  structured  as  a  series  of  experiments.  Each  experiment  is  based  on 
a  simple  process-control  problem  that  (we  feel)  epitomizes  some  aspect  of  process-control  program¬ 
ming.  We  started  with  the  simplest  process-control  problem  imaginable — a  sequential  control- 
program  running  on  a  single,  fault-free  processor.  By  reading  sensors  and  writing  to  actuators,  this 
program  controls  an  on-going  physical  process.  Solving  this  problem  required  reasoning  about 
control-program  execution  times,  something  that  has  long  been  considered  an  integral  pan  of 
process-control  programming.  We  were  well  aware,  however,  that  any  conclusions  from  this  experi¬ 
ment  would  have  to  be  regarded  as  tentative.  By  considering  a  sequential  control-program,  problems 
arising  due  to  resource  contention  were  being  ignored;  and  by  assuming  a  fault-free  processor,  com¬ 
plications  associated  with  implementing  fault -tolerance  were  being  ignored. 

Simplifying  assumptions  not  withstanding,  our  first  experiment  did  lead  to  some  insights  about 
the  use  of  asseraonal  reasoning  in  wnting  process-control  programs.  These  insight*  are  the  subject  cf 
this  paper.  In  section  2,  we  describe  extensions  to  Dijkstra’s  weakest-precondihon  calculus  [D76] 
[G84]  that  we  found  necessary  for  deriving  sequential  process-control  programs.  Section  3  illustrates 
the  use  of  these  extensions  and  the  calculus  by  giving  an  example  derivation  of  a  control  program. 
Conclusions  appear  in  section  4. 


2.  Using  Weakest  Preconditions  with  Physical  Processes 

Process-control  problems  are  often  specified  in  terms  of  restrictions  on  permissible  states  of 
some  given  physical  system.  To  prevent  these  restrictions  from  being  violated,  a  control  program  is 
constructed.  By  setting  actuators  to  manipulate  the  process  being  controlled,  the  control  program ,  ,or 
ensures  that  none  of  the  proscribed  states  is  ever  entered.  The  actions  of  a  control  program  are,  there-  4  j  ^ 
fore,  closely  linked  to  the  state  of  the  physical  process  being  controlled.  Consequently,  when  deriv- 

ing  a  control  program,  it  is  necessary  that  we  be  able  to  reason  about  both  the  program  state  and  the  t  j  _ 

state  of  the  physical  process  being  controlled.  - 

Assertional  methods  for  deriving  programs  are  based  on  manipulating  logical  formulae,  called  -  —  - 

1  on/ 

assertions,  that  characterize  sets  of  program  states  Gn<-  way  to  employ  assertional  methods  in  the  —  — 

Cod 0 3 

design  or  d  process-eonuot  program  is  to  augment  the  program  state  space  so  that  it  includes  t  atJd/or  — 

oist  '  special 


□  □ 


information  about  the  state  of  the  physical  process  being  controlled.  Doing  so.  however,  requires 
extending  the  rules  used  to  reason  about  program  execution: 

'  1 )  During  execution  of  a  program  statement,  changes  occur  to  the  state  of  the  physical  process 
being  controlled  Rules  characterizing  the  effects  of  program  execution  must,  therefore,  be 
modified  to  reflect  these  other  state  changes. 

(2)  Statements  whose  execution  involves  interaction  with  sensors  and/or  actuators  must  be 
axiomahzed  as  rules  relating  states  before,  during,  and  after  execution. 

The  remainder  of  this  section  discusses  these  extensions. 

Reality  Variables 

The  state  space  of  physical  system  is  usually  defined  by  a  collection  of  state  components,  each 
of  which  is  indexed  by  some  independent  parameters.  For  example,  the  state  of  a  railroad  train  at  a 
time  T  can  be  characterized  by  its  position  X(T),  its  speed  V(T),  and  its  acceleration  A(T).  N'ote  that 
the  choice  of  ume  as  the  independent  parameter  is  arbitrary.  If  its  velocity  is  always  greater  than  0, 
then  a  train  at  position  X  could  equally  well  be  described  by  time  T(X),  speed  V(X),  and  acceleration 
A(.Y).  As  physicists  learned  long  ago,  quantities  that  are  convenient  for  the  task  at  hand  should  be 
selected  as  the  independent  parameters. 

The  state  space  of  a  program  can  be  augmented  to  include  the  state  of  a  physical  process  by  pos¬ 
tulating  additional  program  variables.  For  each  state  component  Q,,  we  add  to  the  program  state 
space  a  function-valued  program  variable  q,,  called  a  reality  variable .'  Each  reality  variable  repli¬ 
cates  (in  the  program's  state  space)  information  about  a  physical  system  during  program  execution. 
Initially,  the  domain  of  a  reality  variable  q,  will  be  empty,  as  the  independent  parameter  P,  for  ex¬ 
changes,  the  domain  of  q,  is  extended  to  include  the  values  over  which  P,  has  ranged.  Reality  van- 
ables  are  entirely  fictional  They  allow  us  to  describe  and  reason  about  the  state  of  a  physical  system 
by  using  assertions,  but  they  are  not  actually  maintained  in  memory.  Thus,  they  are  a  form  of  auxili¬ 
ary  vanable  [C73]. 

In  defining  and  manipulating  expressions  involving  function- valued  program  variables,  like 
reality  variables,  it  will  be  convenient  to  have  some  notation.  Following  [G84],  given  a  function  / 
with  domain  domif),  the  function  expression 

if  -  x  €  D:g(x)) 

is  defined  to  be  a  function  whose  domain  is  domif)  uD  and  whose  value  at  any  point  a  in  this 
domain  is:  g(a )  if  a  e  D  and  /(a)  otherwise.  As  a  notauonai  convenience,  we  define- 


’In  the  sequel,  we  use  upper -cue  identifiers  to  denote  physical  slate  components  arid  the  cnTTwarmr'di-e  lower  cue 
identifier  to  denote  the  .  iHtv  v.-r^er  -Ha*  mod*: 
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</:  xeD.idK  xeD'.h(x))  =  Kf:  x  e  £>:  xeD':fi(x)). 

And.  in  specify  mg  a  domain,  we  use  the  notation  low  hi<>h  to  denote  the  set  { a  \  low  <a  <hiqh  j . 

Preserving  the  Fiction:  Updating  Reality  Variables 

The  state  of  a  physical  system  is  changed  by  a  physical  process.  Typically,  these  changes  are 
charactenzed  by  a  set  of  equations  relating  the  values  of  various  state  components  to  current  and 
recent  values.  We  cannot  expect  a  physical  process  to  update  the  reality  variables  being  used  by  the 
control  program  for  modeling  the  state  of  a  physical  system.  And,  since  the  weakest-preccndition 
calculus  is  based  on  the  presumption  that  all  changes  to  the  truth  of  an  assertion  (being  evaluated  on 
the  program  state)  are  the  result  of  program  execution,  we  have  no  choice  but  to  regard  the  program 
itself  as  performing  updates  to  reality  variables.  By  using  the  same  laws  of  Physics  that  characterize 
changes  to  the  state  of  the  physical  process,  it  is  possible  for  program  statements  to  compute  updates 
to  the  reality  variables. 

Consider  some  physical  state  component  Q(P)  being  modeled  by  a  reality  variable  qip),  and 
suppose  that  as  long  as  no  actuator  changes  during  some  interval  from  P  to  P+ 5,  changes  to  Q  are 
charactenzed  by  the  following  equation. 

(2.1)  Q(P+&)  -  7(Q(P),  A)  forOSASS 

Let  (S) a  denote  a  statement  whose  execution  coincides  with  a  change  of  5  of  parameter  P  Then,  exe¬ 
cution  of  (5 >8  is  equivalent  to  executing  S  and.  as  part  of  the  same  atomic  action,  changing  p  and  q  in 
accordance  with  (2.1).  This  state  change  can  be  modeled  by  a  program  fragment: 

(S)5:  S;  p.  q  :=p+5.  (q\  lep  p+b:  J(q(p),  i-p)) 

Using  the  weakest-precondition  predicate  transformers  for  multiple-assignment  and  statement  compo¬ 
sition,  we  obtain  the  following  predicate  transformer  characterization  for  (S)8. 

wp«5)8.  R) 

=  «wp  definition  of » 

wp(S.  wp(p,  q  :=p+5.  (q;  i  e  p  ..p+8:  f(q(p),  i-p)),  R)) 

=  -ovp  definition  of 

*V(S,RPP& 

,  (<f;  i  *p  p*i-  7(q(p).>-p))^ 

Notice  that  when  the  independent  parameter  5  in  (S>8  models  the  passage  of  time.  (S>8  is  a 
statement  that  executes  for  5  seconds.  The  definition  of  wp((S)8,  R)  then  asserts  that  after  executing 
(S)i  the  current  time  has  been  incremented  by  5  and  all  other  reality  variables  have  been  updated  as  if 
o  seconds  had  passed.  However,  our  characterization  of  (S)g  also  allows  the  independent  parameter  8 
to  be  a  quantity  other  than  lime,  making  it  possible  to  reason  in  the  coordinate  system  lect  suited  tor 
the  problem  at  hand.  Also  notice  that,  according  to  our  weakest  precondition  characterization  of  (S>8, 
an  ordinary  statement  5  must  be  regarded  as  being  equivalent  to  <S)o.  This  is  because 
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wpt\S>o.  R  >  =  vvp(S.  R ) 

holds. 

To  illustrate  the  use  of  wp(<S) 5,  /?)  in  an  actual  process-control  programming  problem,  suppose 
we  are  interested  in  controlling  the  speed  of  a  railroad  train.  Define  reality  variable  v(x>  to  be  the 
speed  of  the  train  when  at  a  given  position  x.  From  Newton’s  Laws  of  Motion,  we  know  that  if  a 
train  does  nui  accelerate  during  an  interval  of  8  seconds,  then  reality  variable  v  can  be  characterized 
by  the  following  equation: 

(2.2)  v(x+A)  =  v(x)  forO<A<v(x)*S 

Thus,  according  to  our  definition  for  wp((5)s,  R),  we  have  the  following  weakest  precondition  char- 
actenzation  for  a  statement  <S) s  that  takes  duration  6  seconds  and  is  executed  while  a  train  is  not 
accelerating. 

yyp((S >5,  R) 

=  *<(2.2)  and  np  definition  for  (5)8» 

up(S,R  (v;  1  Cl  l  +  v<x)«8:  v(x»  ) 

Interacting  with  a  Physical  Process 

To  have  broad  applicability,  a  method  for  reasoning  about  process-control  programs  must  not 
restrict  the  types  of  sensors  and  actuators  that  it  can  handle.  In  methods  (like  the  weakest- 
precondiuon  calculus)  where  all  state  changes  are  attributed  to  execution  of  statements,  rules  for  rea¬ 
soning  about  the  effects  of  sensors  and  actuators  arc  derived  by 

( 1 )  modeling  these  effects  as  updates  to  reality  variables,  and  then 

(2)  using  the  rules  provided  for  reasoning  about  ordinary  statements  to  derive  rules  for  the  state¬ 
ments  being  modeled. 

As  long  as  the  updates  to  reality  variables  correctly  capture  the  effects  of  the  sensor  or  actuator,  the 
resulting  rules  will  be  sound  and  can  be  used  to  reason  about  how  a  .ont ;  program  interacts  with  the 
process  it  controls.  ■  - 

To  illustrate  how  sensors  and  actuators  are  modeled,  we  return  to  railroad  control.  We  consider 
an  actuator  go <r)  and  a  sensor  await(c).  Executing  go(r)  causes  the  train  to  stan 
accelerating/decelerating  with  some  maximum  constant  acceleration  ACC  (say)  until  target  speed  t  is 
reached;  execution  terminates  only  when  the  train  reaches  its  target  speed,  await(c),  if  invoked  while 
the  train  is  not  accelerating,  delays  execution  of  a  program  until  the  train  is  at  location  c.2 


Tf  go</)  *1  the  only  actuator  that  cm  cause  acceleration,  then  the  condition  that  awah(c)  is  never  executed  while  the 
tram  i«  accelerating  is  equivalent  to  stipulating  that  a  train  is  controlled  by  s  single  sequential  program. 
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Define  Vlenui.  n  to  be  the  distance  that  a  train  travels  while  it  is  accelerating  from  speed  u  to 
target  speed  r.  __ 

i'ieruu.n  =  |(ii*-i:);i2MCO! 

And,  define  I'jnw.  t.  xt  to  be  the  speed  of  a  train  after  having  traveled  x  meters,  0<x<Vlen\u,  n. 
fr-'m  the  point  at  which  it  staned  accelerating  from  speed  u  to  t: 

r  — ; - 

Au‘  -r2*x*ACC  if  u  <t 

\'ai(u.t.x)  =  <i'*u2-2*x*ACC  if  u>c 

u  ifr=u 


The  effect  of  execuung  go(r)  can  be  modeled  as  an  update  to  reality  vanables  x  and  v.  The 
value  of  x  is  increased  by  Vlen(  v(x),  t)  and  the  domain  of  v  is  extended  to  include 
x  x  +  Vlen(v(x),  t): 

gc XT):  x.  v  :=  x+Wen(v(x),  t),  (v;  lex  .  x  +  Vlen(v(x),  t):Vat(v(x), l-x)) 

Even  though  execuung  go(f)  actually  prescribes  changes  to  actuators,  this  multiple-assignment  state¬ 
ment  model  does  provide  a  basis  for  calculating  wp<go(f ),  R): 

wp(go(r),  R) 

=  -model  of  go(r)» 

w p(x.  v  :=x  +  V7en(v(x),  t),  (v;  lex  x  +  V7en(v(x),  t):  Vat(v(x),  t,  l-x)),R) 

=  «wp  defimtion  of  ":= "» 

R  i+Vltn(v(x). /),  (»;  I  Ei  x  +  VUh(v(x),  t):  Vai(*(x).t,  l-x)) 

Similarly,  await(c)  can  be  modeled  by  an  alternative  command: 
await(c):  if  x£c  a  0<v(x)  -*  x,  v  :=  c,  (v;  lex  c:v(x))fl 

Our  model  for  await(c)  updates  reality  variables  x  and  v  if  x£c  and  0<  v(x)  hold;  otherwise,  it  delays 
forever.  Using  the  weakest  precondition  for  if,  we  can  calculate  a  weakest  precondition  predicate 
transformer  for  await(c);  *  ~ 

Hp(await(c),  R) 

=  -model  of  await(c)* 

wp(ifxSc  aO<v(x)— *x,  v  ;=c,(v;  lex  .c:  v(x))  fl.  R) 

=  *wp  definition  of  lf» 

xSc  a  0<v(x)  a  (xSc  a  0<v(x)  =>  wp(x,  v  :=  c,  (v;  lex  .  c:  v(x)),  R)) 

=  *wp  definition  of  and  predicate  logic* 

x£c  A  0<v(x)  A  l,x  c  v(x)) 
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3.  An  Example 


Other  than  the  extensions  mentioned  above,  the  methodology  of  !D76j  and  [G84]  for  deriving 
ordinary  sequential  programs  can  be  used,  unchanged,  for  deriving  sequential  process-control  pro¬ 
grams.  In  this  section,  we  illustrate  that  methodology  with  a  simple  railroad-control  problem. 

Railroad  tracks  are  typically  partitioned  into  segments,  called  blocks.  Each  block  i.  has  an 
associated  starting  location  b,  and  ending  location  b^\  where  b,<b,» \.  and  a  range  of  per¬ 
missible  speeds  mn,  mxt  where  0<mn,  <mxl.  Desired  is  a  program  to  control  the  speed  of  a 
point  train-’  so  that  it  travels  from  b o  to  b„,  maintaining  safe  speeds  along  the  way.  Use 
gom  and  await! cl,  as  defined  above,  for  interactions  between  a  single  sequential  control 
program  and  the  train. 

The  train  has  made  a  safe  passage  from  location  a  to  b  provided  the  following  holds. 

S  afe(a.b):  a  b<zdom{v)  a  (V/:  a<>l<b\  b^l^b^x  =>  mnt<>v(l)<mxt) 

The  first  conjunct  of  Safe  (a,  b)  asserts  that  the  train  has  actually  traveled  from  a  to  b,  and  the  second 
conjunct  asserts  that  the  train's  speed  satisfied  the  restrictions  associated  with  each  block  it  occupied. 
Using  Safe  (a.  b ).  we  .an  specify  the  above  railroad  control  problem  in  terms  of  weakest  piecondi- 

uons: 

1 3.1)  i=b0  av=(;  60:v0)  =o  wp(S.  Safe(b0,  b„)  a  x=bn) 

This  formuia  constrains  S  to  be  a  program  that  terminates  with  the  train  at  location  b„  after  having 
traveled  at  safe  speeds  to  get  there,  provided  5  is  started  with  the  train  at  location  b0  traveling  with 
speed  v0.4 

Having  formalized  the  specification  for  a  correct  control  program  S,  we  now  proceed  with  the 
derivation.  The  universal  quantifier  in  conjunct  Sctfeib o,  b„)  of  the  result  assertion  is  a  tip-off  that  a 
loop  should  be  tned  for  S.  Thus,  we  employ  a  standard  hueristic  from  [G84] — replacing  a  constant 
by  a  vanable — and  derive  a  loop  invariant  from  the  result  assertion.  Replacing  n  in  the  result  asser¬ 
tion  by  a  new  program  vanable  h  (for  "here")  we  get; 

/:  Safe(bo,  b*,)  x=6*  a  0£h£n 

Since  /  a  h=r,  implies  result  assertion  Safe(b o,  bm)  a  x=bn,  we  conclude  that  the  loop  guard  must  be 
h  *n  (or  something  that  implies  h  *n)  and  conjecture  that  S  has  the  following  structure: 


’Asaunung  a  point  train  u  not  •  fundamental  ajaumption,  but  wilt  nmpiify  tome  of  what  follows.  By  using  a 
configuration  space  transformation  [LP83],  the  control  problem  for  a  length  L  train  can  be  trantformed  to  a  control  problem 
for  a  pomt  vain  on  a  track  with  additional  blocks. 

4If  the  conjunct  x =6,  is  omitted  from  the  result  assertion,  then  it  would  be  permissible  for  control  program  5  to  ter¬ 
minate  long  after  the  vain  had  peased  point  bm.  We  have  deemed  such  behavior  to  be  unacceptable  and  have  ruled  it  out. 


■V 
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5  5,  :/} 

do  h*n  —*  [I  *  h*n)  S  ;  ( /  j  od  { h  =  n  a  I } 
iSjfetb0.  bh)} 

Program  5  will  satisfy  its  specification  provided  we  find  statements  5 1  and  5;  that  satisfv  the  follow¬ 
ing  specifications. 

1 3.2 )  bo  av=i;  bo'.vo)  =>  wp(5i , /) 

1 3 . 3 )  /  a  h  *  n  wp  ( S ; ,  / ) 

Formula  (3.2)  is  the  specification  for  the  loop  initialization;  (3.3)  is  the  specification  for  the  loop 
body. 

According  to  specification  (3.2),  5 1  must  establish  /.  Observe  that  an  easy  way  to  establish  /  is 
by  setting  h  to  0.  So,  we  use  wp  to  calculate  an  assertion  that  must  hold  before  executing  h  :=  0  in 
order  for  /  to  hold  afterwards. 

wp(A  :=  0.  /) 

=  «wp  definition  of 

(Safi f(o0.  iV  A  a  0<A</i  >o 
=  ‘textual  substitution* 

Safe(bo.bo)  a  x=b0 
=  ‘definition  of  Stfe(a.  b)» 

b0edom(v)  a  mn0<,v(bQ)^mxo  a  x=f>0 

Notice  that  x=b0  a  v=(;  b0:v0),  the  antecedent  of  specificabon  (3.1)  for  S.  implies  w p(h  :=0 . /) 
only  if  mnQZv0Smxo-  Thus,  executing  A  :=0  establishes  the  loop  invariant  only  under  cenain 
conditions — the  initial  speed  of  the  train  must  be  safe  for  travel  in  block,  bo- 

Assumption  1.  m/i0<lvo  <mxo 

In  retrospect,  this  requirement  should  not  be  surprising.  What  is  worth  noting,  however,  is  that  this 
implicit  assumption  was  exposed  simply  by  adhenng  to  a  rigorous  calculus  in  deriving  the  program. 

We  have  derived  following  structure  for  the  loop. 

5:  {x-bo  a  v=C  fTo^o)  A  mnoSv0<mxo| 
h  :=  0  {/} 

do  h*n  — »  (/  a  A*n)  S2  {/ }  od  (A=/ia/} 

{Safe(b0.bk)) 

We  now  refine  Si,  the  body  of  the  loop.  Based  on  our  choice  of  guard,  we  know  that  the  loop  will 
terminate  when  h  equals  n.  Initially,  A  is  0.  Thus,  for  52  to  make  progress  towards  termination,  h 
must  be  increased;  and  for  52  to  satisfy  specification  (3.3),  52  must  reestablish  /.  To  investigate  the 
feasibility  of  increasing  A  by  l,  we  calculate  wp(A  ;=  A  + 1,  /). 

wp(h  :=A  +  1,/) 

=  «wp  definition  of 
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( Safe(b0,bH )  a  x=6*  a  0565/!))!,, 

=  -textual  substitution* 

Safe(b0,  bhZ\)  a  x=bh+\  aOS6  +  15/i 
*s  -o565c  =»  ( Safe(a.c )  ■  ( Safe  (a ,  6)  a  Safe(b,  c)))* 

Safe(bo.bk),A  Su/e(6*.  6*4.1)  a  x*bk+\  a  056+lSn 

Since  1  /\h*n  holds  at  the  start  of  S2.  we  know  that  the  first  and  last  conjuncts  of  Kp(6  :=h  +  \,  l) 
hold  before  S2  executes.  We  must,  therefore,  arrange  for  the  remaining  conjuncts  to  hold. 

Safe(.bh,bk+\)/\x=bh+\ 

=  -definition  of  Safe(,a,  6)* 

bh..bk+\<zdom{v)  a  (V/:  6*£/S6;.,.|:  6,5/56,4-1  => mn,5v(/)5mx,)  a  x=bk+\ 

=  -x=6*,.|  =^0..  6*4.1  cd6m(v)» 

(V/:  6*5/56*4. 1:  6/5/56/4. t  =* m/t,5v(/)5/nx,)  a  x»6*4., 

=  -predicate  logic* 

(3.4)  (V/:  6*5/56*4.  1:  6/5/<6,4. \  =*m/t/Sv(/)5mx,) 

a  maxCm/iA./n/jA^OSvfftA^i)^^^*,^**,)  a  x=6*4-i 

We  consider  the  final  conjunct  first  It  is  easy  to  establish  by  using  await(6*,.|),  so  we  compute: 

Hp(await(&A+i);  h  :»6  + 1.  (3.4)) 

3  «wp  calculus* 

x56*4-i  a  0<v(x)  a  ((VI:  6*5/56*4-1 :  6/5/ <6,4.1  =>  mnjZv(l)ZmXi) 
a  max(mn*.mn*.4i)5v(6*+i)5min(mx*,mx*4,)  a  x -6*4.1 ){;’.(,;  /«* 

3  -textual  substitution* 

x  56*4-1  a  0<v(x) 

a  (V/:  6*5/56*4.1:  6,5/<6,4.|  =>m/i,5(v;  /ex..6*+1:v(j)X/)S;TOt1) 
a  max(mn*,m/i*4.,)5(v;  /e  x..6**i:  v(x)X6*4.|)£min(mx*.mx*4.i) 

A  6*4.1  “6*4.1 

3  -predicate  logic* 

(3.5)  x56*4.|  a  0<v(x)  a  (V/:  6*5/56* 4,,:  6/S/<6, 4.1  =>  wi,  5  v(/)  5 mx,) 

a  max(m/i*.  m/i*4.|)5v(6*4.|)5min(mx*.  mx*4.|) 

The  first  conjunct  of  (3.5)  is  implied  by  x»6*  in  /  (because,  by  assumption,  6*5:6* 4.1).  The  final  con¬ 
junct  can  be  established  by  executing 
S2:  go(T);  await'(6*4.|) 

where  x  is  any  speed  that  is  safe  and  is  attainable  by  accelerating  from  v(6*).  That  is,  t  must  satisfy: 

(3.6)  raax(mn*,mn*4.i)itimin(m**,mx*4.|)  a  V'/e/i(v(6*),x)56*4.|-6* 

Nothing  stated  thus  far  implies  that  it  should  be  possible  to  accelerate  from  any  safe  v(6*)  to  a 
safe  v(6*4.i)  to  it  most  a  distance  of  6*+t-6*.  and  so  without  making  further  assumptions  about 
speed  constraints,  the  problem  is  unsolvable.  We  have  uncovered  another  hidden  assumption 
required  to  control  a  train: 
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Assumption  2.  (Vi ,r:  0</<n  Amaxtmn^^mn/iSjrSminfmXj.j,^): 

(3j':  max(mn(,mnl4.1)Sj'Smin(/ru,,m4t,+i):  Vfoifr.  j')£hi*i-M) 

Henceforth,  we  assume  that  speed  constraints  for  blocks  do  satisfy  Assumption  2.  fit  is  not  difficult 
to  prove  that  any  control  problem  for  which  there  is  a  safe  path  from  b0  to  bH  can  always  be  reformu¬ 
lated  as  one  with  more  restrictive  minimum  and  maximum  speeds  satisfying  Assumption  2.) 

A  target  speed  t  satisfying  (3.6)  can  now  be  computed  as  follows.  First,  due  to  the  definition  of 
Vlen(u,  (),  the  set  of  attainable  speeds  s — both  safe  and  unsafe — starting  from  position  b*  is  charac¬ 
terized  by: 

^(bh)l-2*ACC^b^x-bk)  is  S  Vv(b*)2+2MCC*(&*+i-^) 

Second,  the  set  of  safe  speeds  s  for  location  bk+\  is  given  by: 
max(mn*.  mn>,+|)  S  j  S  min(mx*,  mx^i) 


The  intersection  of  these  sets,  therefore,  is  the  set  of  safe  and  attainable  speeds;  the  maximum  of  this 
intersection  is  the  greatest  safe  speed — time  is  money  for  a  railroad. 

t  =»  min Nv(b*)2  +2MCC •(&*♦! -6*) .  m**.  mxk+\) 

Using  this  value  of  x  for  the  target  speed  ensures  that  the  final  conjunct  of  (3.5)  will  hold. 

The  penultimate  conjunct  of  (3.5)  now  is  implied  by  our  choice  of  x  and  the  fact  that 
mn*£v(6A)£min(mxA,mxA+i),  which  is  implied  by  ScfefJjQ,  b*).  Thus,  our  only  remaining  obliga¬ 
tion  is  the  truth  of  the  second  conjunct  of  (3.5),  0<v(x).  Recall  that  0 £mn/<mx<,  by  assumption. 
Thus,  for  all  i,  mx,*0  and  so  successive  values  of  t  are  each  non-zero.  Provided  v0*0,  we  can 
strengthen  the  loop  invariant  to  include  0<v(x)  as  a  conjunct.  This  results  in  the  following  program. 

S:  (x»6oav«(;  6o:v<>) Amno^vo<mxoJ 
h  :»0 

(/:  Sqfe(bo,b),)  a  x»b*  a  Oihin  a  0<v(x)) 
do  h+n  -+  {/  Ah*n) 

S{  r :■  mlnWv(b*)J +2MCC  *(b^i  -bk) ,  mxh,  mxk*i)\ 
go (r); 

•w ait(b*«.|); 
h 

(/} 

od  (A*«a/) 

(Stfe(&o.*»)) 

As  the  final  step  of  the  derivation,  we  delete  references  to  reality  variables  horn  program  state¬ 
ments.  Recall,  reality  variables  are  auxiliary  and,  therefore,  may  not  affect  program  execution.  The 
only  reference  to  a  reality  variable  from  within  statements  In  the  program  above  is  the  expression 
v(bH).  We  can  maintain  this  value  in  a  program  variable  vet  by  strengthening  the  loop  invariant  and 
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adding  assignments  after  each  go  statement.  Making  these  changes  results  in  the  following  control 
program,  it  solves  the  railroad  control  problem. 

S:  />o:vo)AffwoSvo<ff«n) 

h  :=  0;  vel  ;=  v0 

{/:  Safe(bo,bh)  a  x=hA  a  Q£h£n  a  0<v(x)  a  vW= ) 
do  h  *n  — ►  {/  a  h  } 

S2  t  :* min(Vve/2+2MCC *(6^! -6*) ,  mx*.  mxA+i); 
go(r); 
vel  :=  r; 
await(h^i); 
h  :=  /»  + 1 
(/) 

od  {/i=n  a  /} 

(5j/e(h0.^)l 

Note  that,  although  correct,  this  control  program  does  not  always  peimit  a  train  to  travel  as 
quickly  as  possible.  Modifying  the  derivation  to  maximize  train  speed  is  not  difficult,  however. 
Instead  of  first  attempting  to  establish  the  final  conjunct  of  (3.4),  we  instead  concentrate  on  the  penul¬ 
timate  conjunct.  The  loop  body  that  results  when  this  strategy  is  pursued  turns  out  to  be  somewhat 
different  from  the  one  we  derived.  The  alternative  loop  body  is: 

go(ri);  awalt(&A+i-V7en(r|,r2));  go(r2);  /i:*/i  +  1 
where  rt  and  r2  are  the  largest  speeds  satisfying: 

Vlen(y(bh),t\)+Vlen(t\,t2)i,bk+\-bh  a  mnhZt\£mXk 

a  max(m/i*,/n/tjk+|)Sr2imin(mx*,mx*^i) 

Second,  note  that  our  control  programs  can  be  easily  modified  for  the  case  where  the  assign¬ 
ments  to  r  and  h  are  not  instantaneous.  The  predicate  logic  details  become  a  bit  messier,  but  nothing 
of  substance  changes. 

4.  Discussion 

a  — 

We  were  pleased  to  discover  that  only  minor  modifications  were  needed  in  order  to  employ 
Dijkstra’s  weakest-precondition  calculus  in  deriving  sequential  process-control  programs.  Dijkstra’s 
calculus,  unfortunately,  is  baaed  on  regarding  a  program  as  a  relation  between  sets  of  states  and, 
therefore,  does  not  scale-up  well  to  concurrent  and  distributed  programs,  which  are  best  thought  of  as 
"invariant  maintainers".  The  extensions  derived  in  section  2  for  handling  the  state  of  a  physical  pro¬ 
cess  do  scale  up.  For  example,  we  have  been  able  to  use  them  along  with  a  logic  for  proving  arbitrary 
safety  properties  of  concurrent  programs,  Proof  Outline  Logic  [SA86], 

Reality  variables  are  history  variables— they  encode  in  the  current  program  state  information 
about  past  system  states.  Using  history  variables  for  reasoning  about  programs  is  usually  a  bad  idea, 
because  it  introduces  distinctions  that  should  be  irrelevant  The  current  state— not  how  it  was 
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computed — should  be  ot  concern  when  reasoning  about  what  a  program  will  do  next.  In  reasoning 
about  process-control  systems,  however,  one  has  no  choice  but  to  employ  history  vanables  of  some 
sort.  This  is  because  the- past  instants  for  which  the  state  of  a  physical  process  is  defined  is  a  strict 
superset  of  the  past  instants  for  which  the  state  of  a  control  program  is  defined.  A  program  imple¬ 
ments  a  discrete  transition  system,  while  a  physical  process  is  likely  to  implement  a  continuous  tran¬ 
sition  sy  stem.  History  vanables  allow  us  to  reason  about  ail  of  the  behavior  of  the  physical  process, 
including  those  states  that  ex.st  while  the  program  state  is  in  transition,  hence  undefined. 
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